The widespread use of computers for information storage and processing has resulted in the need for systems which can protect information which is of national security importance, commercially sensitive, or personal. Security measures are required which test users of computer systems security against unauthorised access to and modification of information stored in and processed by computer systems.
In response to the need for secure computers and computer systems for operation within classified environments, the United States Department of Defense has published the "Department of Defense Trusted Computer System Evaluation Criteria" (reference No DOD 5200.28-STD). This publication, typically referred to as the Orange Book, describes security measures including measurable objectives and evaluation criteria for assessing secure computers and computer system designs and implementations.
The Orange Book emphasises the concepts of the Trusted Computing Base (TCB) and the reference monitor. The TCB is the set of all resources in a system that together provide the security features of the system. The reference monitor is that part of the TCB which oversees all data accesses in the system, and will only permit those accesses that the user of the system has the authority to perform.
An approach taken by system developers in response to Orange Book security criteria was to implement TCBs into existing hardware platforms rather than develop completely new hardware, because of the large amount of capital investment in existing computer hardware. This approach meant that the TCB had to be implemented in software, and due to the functional requirements of the TCB and reference monitor, large and complicated software systems were developed from the ground up. This meant that the developers had to develop operating systems and kernels with built-in security in order to produce systems that satisfied the Orange Book Criteria.
However, efforts to build TCBs in such a manner have shown that there are a number of problems with this approach, namely:
(i) Increased development effort. The fact that the TCB is implemented in software means that extra effort had to be made to provide assurance that the TCB would function correctly. Verifying the correct operation of the TCB has proven to be an extremely time consuming exercise and can even be considered impractical if the TCB is too large. PA0 (ii) Decreased performance. Applications running on a software implemented TCB will be slower since the TCB uses processor resources to perform security functions. Additionally in an effort to reduce the verification requirements on the TCB, the size of the TCB can be reduced by eliminating some of the functionality, which in turn reduces the performance of the whole system. PA0 (iii) Reduced usability. The redesign of operating systems and kernels in order to implement a TCB in many cases has been quite extensive. This has resulted in incompatibilities between existing software and the new secure operating systems, which reduces the usability of the TCB. The security functions imposed by the TCB are often viewed as too restrictive by the users, as they can obstruct the users performing even routine tasks. PA0 (iv) Decreased maintainability. Any changes that might be made to a software implemented TCB require that the TCB be re-evaluated, and this makes it difficult to add functionally to the TCB incrementally.
Different approaches were tried for developing trusted systems, including implementing the reference monitor in hardware so as to avoid many of the problems inherent with software implementation. One prior art design is the US National Computer Security Center's Logical Coprocessing Kernel which is commonly known as LOCK. The LOCK project involved the development of a reusable hardware module called SIDEARM (System-Independent Domain-Enforcing Assured Reference Monitor) that could be fitted to a number of systems and implemented a hardware version of the reference monitor function. The project also required the porting of an existing operating system (UNIX) onto a LOCK hardware platform.
Whilst the LOCK project showed that hardware implemented reference monitors avoid many of the problems of software TCB development, the development of LOCK style systems is still very time consuming and expensive. Additionally the SIDEARM is closely integrated into the particular resources of the hardware system it runs on and it remains to be seen if the LOCK design can be applied to a number of different hardware systems.
Abrams has proposed a generalised TCB software architecture for implementing trusted systems. Abrams proposed that the TCB be composed of a number of TCB subsets, each of which is responsible for providing some security-related functionality. This is basically a "divide and conquer" approach, where the TCB is split into a number of protection domains and the design includes a structure for implementing interdomain communications and making access control decisions that involve a number of domains.
The Abrams generalised TCB architecture is a framework for developing trusted systems from a software perspective. Abrams claims that once the framework has been refined and perfected then it would be possible to build hardware modules that implement the generalised TCB architecture and fit them into existing systems, in much the same manner as LOCK devices. It is not immediately evident how this might be implemented, and even if it will eventuate.
Whilst the developers of trusted computing platforms have not yet delivered suitable technologies for general purpose computing, others have integrated trusted functionality into existing general purpose systems.
For example, there exist untrusted general purpose computer systems which can be retrofitted with trusted hardware peripherals. These peripherals are arranged to provide services which enforce trust in a particular function of the untrusted computer.
One such device is specifically designed for use with an electrically and physically secure network handling classified data. When users at the secure network wish to send data out of the network, for example using email, they use a trusted peripheral attached to their typically untrusted workstation to apply a tamper-proof seal to the data. The data and seal are then transported over the secure network to further a trusted peripheral that acts as a gateway. This gateway device will check that the seal is valid, ie it verifies the data being sent out of the secure network is the same as that which was sealed, and if so passes the data to the external network.
The coordinated action of the trusted peripherals provides a basic integrity filter function operating on all data leaving the secure network. The use of an integrity filter ensures that the only data which leaves the secure network is that which has been approved by the network users. Thus the retrofitting of trusted peripherals to the secure network has provided trust in a particular subset of the secure network: operation.
The problems described above are typically related to the difficulty and complexity of developing trusted computer software and hardware. The inventors have developed an approach to the design of computer hardware having inbuilt trusted functionality. The same approach can be used to develop a hardware device which is used not unlike a peripheral to an untrusted computer which can provide predetermined security functions to that untrusted computer. The peripheral version of the device is able to be disconnected from the computer as required and may be used with another computer. The peripheral version of the device can be reconfigured to perform other security related functions or predetermined security functions.